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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Access, Terminals, Transmission 
and Multiplexing (ATTM). 

The present document is part 17 of a multi-part deliverable covering Access, Terminals, Transmission and Multiplexing 
(ATTM); Integrated Broadband Cable and Television Networks; IPCablecom 1.5, as identified below: 



Part 1: 
Part 2: 

Pai-t 3: 

Part 4: 
Part 5: 

Part 6: 
Part 7: 
Part 8: 
Part 9: 
Part 10: 
Part 11: 
Part 12: 
Part 13: 
Part 14: 
Partis 
Part 16: 
Part 17: 
Part 18: 
Part 19: 
Part 20: 



'Overview"; 

'Architectural framework for the delivery of time critical services over cable Television networks using 
cable modems"; 

'Audio Codec Requirements for the Provision of Bi-Directional Audio Service over Cable Television 
Networks using Cable Modems"; 

'Network Call SignalUng Protocol"; 

'Dynamic Quality of Service for the Provision of Real Time Services over Cable Television Networks 
using Cable Modems"; 

'Event Message Specification"; 

'Media Terminal Adapter (MTA) Management Information Base (MIB)"; 

'Network Call Signalling (NCS) MIB Requirements"; 

'Security"; 

'Management Information Base (MIB) Framework"; 

'Media Terminal Adapter (MTA) device provisioning"; 

'Management Event Mechanism"; 

'Trunking Gateway Control Protocol - MGCP option"; 

'Embedded MTA Analog Interface and Powering Specification"; 

'Analog Trunking for PBX Specification"; 

'Signalling for Call Management Server"; 

'CMS Subscriber Provisioning Specification"; 

'Media Terminal Adapter Extension MIB"; 

'IPCablecom Audio Server Protocol Specification - MGCP option"; 

'Management Event MIB Specification"; 
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Part 21: "Signalling Extension MIB Specification". 

NOTE 1: Additional parts may be proposed and will be added to the list in future versions. 

NOTE 2: The choice of a multi-part format for this deliverable is to facilitate maintenance and future 
enhancements. 
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Scope 



The present document defines the interface used between the Call Management Server (CMS) and Provisioning Server 
(PS) for the exchange of service provisioning information. The interface employs a Web Service model. Specified in 
Web Service Description Language 1.1 (WSDL 1.1), the interface transports XML encoded objects within Simple 
Object Access Protocol 1.1 (SOAP 1.1) encoded messages over an HTTP 1.1 transport. This interface is secured via 
IPSec. 

The data model transported upon this interface is specifically designed to be extensible, allowing incorporation of as yet 
undefined IPCablecom features and specific vendor extensions. 

The scope of the present document is limited to the provisioning of an IPCablecom CMS by a single service provider. 
Additionally: 

• The CMS provisioning interface is limited to the exchange of service activation data between the CMS and the 
PS. The interface between the PS and the back-office Operations Support System (OSS) is out of scope. 

• CMS element management and network element provisioning (dial plans, etc.) are out of scope. 

• Customer record creation/billing is considered part of the back-office OSS application and is currently out of 
scope. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] PacketCable 1.5 PKT-TR-ARCH1.5-V02-700412: "Architecture Framework Technical Report", 

April 12 2007, Cable Television Laboratories, Inc. 

[2] PacketCable 1.5 PKT-SP-PROV 1.5-104-090624: "MTA Device Provisioning Specification", 

June 24 2009, Cable Television Laboratories, Inc. 

[3] PacketCable 1.5 PKT-SP-SEC 1.5-103-090624: "Security Specificaiton", June 24 2009, Cable 

Television Laboratories, Inc. 

[4] Void. 

[5] Void. 

[6] Void. 
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2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

[i.l] Web Services Description Language. 

NOTE: Available at http://www.w3.org/TR/wsdl . 

[i.2] Simple Object Access Protocol. 

NOTE: Available at http://www.w3.org/TR/SOAP . 

[i.3] XML Protocol. 

NOTE: Available at http://www.w3.org/2000/xp . 

[i.4] DOCSIS SP-CMCI-CO 1-081 104: "Data-Over-Cable Service Interface Specifications, Cable 

Modem to Customer Premise Equipment Interface Specification, CMCI, November 4, 2008, 
Cable Television Laboratories, Inc. 

[i.5] IETF RFC 1 123: "Requirements for Internet Hosts - Apphcation and Support". 

[i.6] Extensible Markup Language (XML) 1.0. 

NOTE: Available at: http://www. w3.org/TR/REC-xml . 

3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

active: service flow is said to be "active" when it is permitted to forward data packets 

NOTE: A service flow must first be admitted before it is active. 

endpoint: Terminal, Gateway or Multipoint Conference Unit 

Internet key exchange: key-management mechanism used to negotiate and derive keys for SAs in IPSec 

local number portability: allows a customer to retain the same number when switching from one local service 
provider to another 

media gateway: provides the bearer circuit interfaces to the PSTN and transcodes the media stream 

pre-shared key: shared secret key passed to both parties in a communication flow, using an unspecified manual or 
out-of-band mechanism 

registration, admissions and status: RAS Channel is an unreliable channel used to convey the RAS messages and 
bandwidth changes between two H.323 entities 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AAA Authentication, Authorization and Accounting 

BPP Basic POTS Provisioning 

CFP Call Feature Provisioning 

CM DOCSIS Cable Modem 

CMS Call Management Server 
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CMS Cryptographic Message Syntax 

CMTS Cable Modem Termination System 

Codec COder-DECoder 

CSR Customer Service Representative 

DOCSIS Data-Over-Cable Service Interface Specifications 

DQoS Dynamic Quality of Service 

ESP IPSec Encapsulating Security Payload 

FQDN Fully Qualified Domain Name 

HTTP Hypertext Transfer Protocol 

IETF Internet Engineering Task Force 

IKE Internet Key Exchange 

IP Internet Protocol 

IPSec Internet Protocol Security 

LNP Local Number Portability 

MGCP Media Gateway Control Protocol 

MIB Management Information Base 

MTA Multimedia Terminal Adapter 

NCS Network Call Signalling 

OSS Operations Support System 

PCSP IPCablecom CMS Subscriber Provisioning 

PS Provisioning Server 

PSTN Public Switched Telephone Network 

RAS Registration, Admissions and Status 

RFC Request for Comments 

SDP Session Description Protocol 

SNMP Simple Network Management Protocol 

SOAP Simple Object Access Protocol 

STP Signalling Transfer Point 

TFTP Trivial File Transfer Protocol 

TLV Type-Length- Value 

UDP User Datagram Protocol 



Void 



Technical Overview 



5.1 



Void 



Figure 1 : Void 



5.2 



IPCablecom Reference Architecture 



Figure 2 shows the reference architecture for the IPCablecom L5 Network. Refer to the Architecture Document [1] for 
more detailed information on this reference architecture. 
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Figure 2: IPCablecom 1.5 Network Component Reference Model 



5.3 Components and Interfaces 



Provisioning is defined as the operations necessary to provide a specified service to a customer. IPCablecom service 
provisioning can be viewed as two distinct operations: MTA provisioning and CMS subscriber provisioning. Figure 3 
presents the provisioning related interfaces maintained by the PS and other authorized Back Office Components to 
various IPCablecom elements. Interfaces not explicitly labelled are undefined and out of scope for IPCablecom. 

The present document is intended to set the requirements for the provisioning interface between the CMS and the PS or 
optionally other authorized Back Office Components (see Pkt-prov-pl in figure 3). 



Back Office 
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(Vendor Dependent Interfaces) 
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CMS 
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Figure 3: Provisioning Component Interfaces 
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5.4 Components 

5.4.1 Back Office Components (Service Provider Business and Service 
Management Systems) 

These are the Back Office Components that a service provider uses to manage customers and other components that 
make up their business. These systems provide the IPCablecom provisioning process with service orders or optionally 
individual workflow tasks to activate services for customers. These systems may also receive accounting or usage data 
used to create customer-billing events. 

5.4.2 Provisioning Server 

This system forms the interface between the provider's Back Office Components and some or all of the IPCablecom 
elements. IPCablecom does not address the implementation of this system or its relationship to other OSSs that a 
service provider might employ. 

The Provisioning Server is defined in [2] as consisting of a provisioning application that contains provisioning logic and 
a provisioning SNMP entity that provides access to active components. Here we will refer to the Provisioning Server 
without distinguishing between these two entities. 

5.4.3 CMS 

The Call Management Server component is described in [1]. This component provides call control and signalling- 
related services for the MTA and CMTS components in the IPCablecom network. 

5.4.4 MTA 

A Media Terminal Adapter is an IPCablecom client device that contains a subscriber-side interface to the customer's 
CPE (e.g. telephone) and a network side signalling interface to call control elements in the network. This component is 
described in [1]. 

5.4.5 TFTP 

A configuration file service that is the basis for most device configuration in an IPCablecom network. This could be a 
standalone TFTP Service that delivers statically-defined files to devices or a dynamic service that creates configurations 
on-the-fly from other data sources. 

5.5 Interface Descriptions 

5.5.1 Pkt-pl 

This interface is defined in [2]. 

5.5.2 Pkt-p4 

This interface is defined in [2]. 

5.5.3 Pkt-prov-pl 

The interface defined in the present document. 
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Assumptions 



• The Back Office components is responsible for coordinating endpoint updates with affected network entities 
(MTAs, CMTSs, etc.) and the CMS. 

• CMS will not play a manager role nor does it specify SNMP communications to an MTA during CMS 
provisioning. 

• The CMS and PS reside in the same secure provisioning domain. Security related information will be outlined 
in the Security Document [3]. 



7 Subscriber Provisioning 

Subscriber provisioning consists of: 

• Customer record/billing support. 

• Equipment setup/configuration. 

7.1 Customer Records (Billing) 

Establishment of a customer record that contains the information needed to deliver service, bill, and collect payment 
from a customer. Customer record creation/billing is considered part of the back office OSS application and is currently 
out of scope for IPCablecom. 

7.2 Equipment Setup and Configuration 

This may include physical installation and/or connection of equipment as well as any software and/or database updates 
necessary to actually deliver the service to the customer. Equipment setup affects two major components in an 
IPCablecom environment: 

• Customer premises equipment. For IPCablecom, this is the MTA. The provisioning for the MTA is defined 
in [2] and will not be discussed in the present document. 

• Call Management Server. Provisioning of the CMS itself can be broken down into two main areas: basic POTS 
provisioning and call feature provisioning. 

7.2.1 CMS Basic POTS Provisioning (BPP) 

BPP provides the CMS with the minimal set of data necessary for routing of simple telephony service (POTS) in the 
IPCablecom network. This minimal set of data consists of a telephone number mapped to its associated MTA's FQDN 
and NCS endpoint identifier. This data will be used to setup translation tables enabling the CMS to route calls to the 
appropriate device/port given a specific telephone number. BPP provisioning for each customer is required before that 
customer can receive any calls in an IPCablecom network. 

7.2.2 CMS Call Feature Provisioning (CFP) 

In addition to BPP, CFP is performed to provide call features to a customer. CFP is more complicated than BPP as the 
parameters passed may vary on a feature-by-feature basis and may also be dependent on vendor specific 
implementations. 
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7.3 Static Versus Dynamic Subscriber Provisioning Data 

Data required by the CMS for subscriber provisioning falls into two classifications: 

1) Static, billed, permanently assigned service state. This data does not change call to call. Examples would be 
DQoS settings, call feature subscribed/non-subscribed states, caller ID information, etc. 

2) Dynamic, non-billed, semi permanent service state. Often this information is subscriber alterable, either at an 
endpoint via *XX key code or via a web interface into the CMS. An example would be the user settable 
parameters of a call feature, such as Call Forward Busy Line (CFBL). The CFBL forwarding number is 
dynamic, non-billed service state. The subscribed/non-subscribed state of CFBL is static data maintained by 
the PS. 

In the IPCablecom CMS/PS scope, the PS owns all static provisioning state, and the CMS owns all dynamic 
provisioning state. 

8 Requirements 

8.1 General Requirements 

• The interface shall make no assumptions regarding PS and CMS implementation technologies. 

Multiple partnering vendors will undoubtedly provide CMS and PS implementations on various hardware, 
software, and development language platforms. A platform and language neutral interface is required. 

• The interface shall support Basic POTS Provisioning. 

The interface's data model shall include the minimum amount of information required to support basic POTS 
service. 

• The interface shall support Call Feature Provisioning. 

The interface's data model shall support subscription to any IPCablecom call feature. 

• The interface's data model shall be extensible. 

The present focus of the interface is telephony data. However, to the extent possible, the interface should be 
extensible for future IPCablecom Multimedia services. It is desirable to have a single, extensible provisioning 
data model and transport to support all IPCablecom features and capabilities, some of which are not yet 
defined. 

• The interface shall not impact any MTA operations in progress. 

Endpoint specific data may be added, deleted, or modified on the MTA without affecting other MTA 
endpoints or sessions in progress. CMS endpoint provisioning scenarios that would result in an endpoint/MTA 
to be taken out of service must be carefully documented. 

• The interface shall be capable of accommodating present (NCS) and future signalling protocols. 



8.2 Transport Requirements 



The transport shall make no assumptions regarding the physical networking infrastructure between a PS and a 

CMS. 

It is anticipated that multiple service providers will be interoperating over a single access network. Thus, 

multiple enterprises will be communicating, potentially using CMS and PS implementations from various 

vendors, over various network infrastructures (firewalls, proxies, etc.). The CMS/PS transport protocol should 

facilitate the ability to penetrate arbitrary network infrastructure. 

The transport shall support unidirectional transfer of single data model objects from the PS to the CMS. 
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The transport shall support efficient streaming of multiple data model objects from the PS to the CMS. 

The transport may support unidirectional transfer of single data model objects from the CMS to the PS. 

The transport may support efficient streaming of multiple data model objects from the CMS to the PS. 

The transport shall include semantics to support new, updated, and removed data model objects. 

The transport shall support informational requests between PS and CMS. 

The transport shall handle conditions such as CMS busy, errors, etc. 

The transport shall provide positive/negative acknowledgement of operation received. 

The transport shall implement an at-least-once type of message semantics. The sender shall not discard its 
request until the receiver acknowledges it (acknowledgements are not acknowledged.) The transport must be 
able to detect data corruption during transport, etc. and notify the sender of such conditions. 

The transport shall provide positive/negative acknowledgement of operation handled. 

The PS shall be able to initiate a transfer of data model objects ("push"). 

The transport shall be secure. 



9 Data Model 

This clause provides a high level description of the PCSP data model and its XML encoding. It is intended as 
descriptive and non-authoritative. The authoritative definition of the data model and its encoding is found in the PCSP 
XML schema in annex A. 

9.1 Overview 

The data model for IPCablecom CMS provisioning is displayed in figure 4. It consists of two categories of entities: 

• Objects. 

• Relations between objects. 



PcspCMS 



■FQDN (key) 
Extensions 



0..* 



PcspService 



Service ID (key) 
Billing ID 
IsPrimary flag 
AdminStatus 
Caller ID params 
Offnet PIC codes 
LNP params 
Announcement params 
Call Feature subscriptions 
Extensions 



0..1 



PcspEndpoint 



-Endpoint ID (key) 
-AdminStatus 
-Codec params 
-Protocol params 
-Extensions 



Figure 4: CMS Provisioning Data lUlodel 



PcspMTA 



■FQDN (key) 

■Port 

■CMTS FQDN 

-Timezone 

■Protocol params 

■Codec params 

■Extensions 
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The following entities shall be supported: 



• The PcspService object is the entity to which an IPCablecom 1.5 customer subscribes. It represents a phone 
number and all related functionality (call features, etc). 

• A PcspMTA object represents a Media Terminal Adapter, which aggregates one or more endpoints physically 
contained within the MTA. 

• The PcspEndpoint object represents a physical endpoint on an MT A/Gateway. 

• A PcspCMS object maintains associations between endpoints/CMSs and services/CMSs. 

• PcspRelations represent associations between objects. In figure 4, they are presented as connections between 
objects. 

PcspService and PcspEndpoint are distinct objects in order to support multiple services (phone numbers) per endpoint. 
Distinct PcspMta and PcspEndpoint objects allow an MTA's endpoints to be managed by different service providers. 
The PcspCms object essentially maintains a collection of endpoints and services. 

All objects are extensible. 

9.1 .1 PcspService Object 

The service object is the entity to which an IPCablecom 1.5 customer subscribes. It represents a phone number and all 
related functionality. The data model allows more than one service to be provisioned to a single endpoint. 

The PcspService object contains the following generic information (for complete details, see the PCSP XML schema): 

Serviceld - a unique identifier for the service. 

Billingld - the identifier of another service, which will be billed for activity on this service. 

IsPrimary flag - with multiple services provisioned upon an endpoint, one service shall have this flag set to 
indicate the default service to use for outgoing calls. 

PrimaryRingPattern - index into MTA cadence table, selecting a ring pattern for this service. 

Administrative status of this service (suspended, enabled, number has changed, etc.). 

DisplayName - the display information used for Call Name Delivery feature (CNAM). 

DisplayNumber - the display information used for Call Number Delivery feature (CND). 

Announcement settings (enable, language, time zone, etc.). 

Carrier codes (long distance carrier code, intra-lata carrier code, international carrier code). 

Local number portability control (porting status, STP lookup flag, etc). 

Call features - A service includes a list of subscribed call feature objects. 

Extensions - This object is extensible in two locations: the main body of the object and the call feature list. 



9.1.2 PcspMta Object 



A Media Terminal Adapter aggregates one or more endpoints (physically contained within the MTA). It contains the 
following generic information (for complete details, see the PCSP XML schema): 

• MTA's FQDN, uniquely identifying this MTA. 

• MTA's NCS listener port (default: 2427). 

• FQDN of controlling CMTS . 

• Time zone within which this MTA is physically located. 
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Signalling protocol designation. This is the default protocol selection for all contained endpoints, unless 
overridden by an individual endpoint. 

Codec designation - default codec selection for all contained endpoints, unless overridden by an individual 
endpoint. 

IPSec Control Flag - The IPSec Control Flag indicates whether IPSec is used for NCS Signalling between the 
CMS and the MTA. By default, IPSec is turned on all endpoints, but can be provisioned otherwise on a per 
endpoint basis. 

MTA Profile Name - Optional; An MTA Profile Indicator identifiable by the CMS. 

A single point for extension. 



9.1.3 PktcEndpoint Object 



An endpoint is a physical port on a MT A/Gateway. It contains the following generic information (for complete details, 
see the PCSP XML schema): 

Endpointid - uniquely identifies this endpoint. 

Signalling protocol selection. Optionally overrides MTA setting. 

Administrative status of the endpoint (disconnected, normal service, test mode, etc.). 

Codec selection. Optionally overrides MTA setting. 

IPSec Control Flag - Optionally overrides the MTA setting. 

A single point for extension. 



9.1.4 PktcCMS Object 



This object maintains associations between Endpoints/CMSs and Services/CMSs. It contains the following generic 
information (for complete details, see the PCSP XML schema): 

• FQDN uniquely identifying this CMS. 

• A single point for extension. 

9.1 .5 Inter Object Relationships 

Within figure 4, the lines connecting the classes represent object "relations" (sometimes called associations). The 
relations depicted in figure 4 shall be supported: 

• Service/CMS. A typical CMS will own a block of phone numbers. 

• Endpoint/CMS. An endpoint requires a CMS for signalling purposes. 

• Service/Endpoint. A phone number must be attached to a physical endpoint. 

• Endpoint/MTA. MTAs physically contain endpoints. 

9.2 Relations are encoded using the PcspRelation entity.XIVIL 
Encoding 

Objects of the data model will be encoded using XML. 
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9.2.1 The PCSP XML Schema 



Annex A contains the PCSP XML schema. The schema defines the XML encoding syntax for the following entities (the 
entities shall conform to the schema): 

• The PcspService, PcspEndpoint, PcspMta, and PcspCms objects. These are the main data model objects. 

• PcspRelation. This is used to establish or teardown relations between objects. 

• PcspImportExport. A general purpose document format that can contain a large number of objects or relations. 
This will typically be used to export full data sets from a PS to a CMS. 

The schema should be employed by validating XML parsers to determine syntactic correctness of encoded entities. 

9.2.2 Sample PCSP Entity Encodings 

Sample XML encodings of all the PCSP data model entities can be found in annex B. 



9.2.3 Object Extensions 



The PCSP XML schema permits extensions for all objects (PcspService, PcspEndpoint, PscpMta and PcspCms). 
Extensions are accomplished via the <Extension> element placed in each object. Most objects specify this element at 
the end of the main body of the object. PcspService includes an additional <Extension> element at the end of the call 
feature list. 

There are a few simple rules for the <Extension> element: 

• All <Extension> elements shall specify a namespace definition. 

• All sub-elements of <Extension> must be namespace qualified. 

These two rules permit the XML parsing system to validate the <Extension> content against a vendor supplied XML 
schema file. Annex C contains an extension example. 



10 Messaging 
10.1 Overview 

The PCSP interface follows a Web Service paradigm. The interface employs SOAP 1 . 1 messages to transfer XML 
encoded entities (from the PCSP data model) between client and server. Messages are transported between client and 
server using the HTTP 1 . 1 protocol. For a complete discussion of the transport considerations, see annex F. 

The interface is modelled on a synchronous request/response pattern (or remote procedure call - RPC). The following 
messaging patterns are supported between client and server: 

• PUT message. Client writes one or more XML encoded objects or relations to the server. Both creation of new 
objects and modification of existing objects are supported. 

• DELETE message. Client requests one or more objects or relations be deleted from the server. 

• GET message. Read one or more XML encoded objects from the server (objects only. . .relations are not 
supported). 

• CMDSTATUS message. Used to transfer "out of band" commands and status between the client and server. 
Client can notify server of various state conditions. Client can command server to perform various actions. 
This message is vendor extensible. 
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10.2 CMS and PS Messaging Role Requirements 

In general, both CMS and PS may be implemented to fully support client and server messaging roles. However, within 
the scope of IPCablecom CMS provisioning, the CMS and PS assume the role requirements specified in table 1 . 

Table 1 : CMS and PS Messaging Roles 



Message 


CMS as client 


CMS as server 


PS as client 


PS as server 


GET 


OPTIONAL 


SHALL 


SHALL 


OPTIONAL 


PUT 


OPTIONAL 


SHALL 


SHALL 


OPTIONAL 


DELETE 


OPTIONAL 


SHALL 


SHALL 


OPTIONAL 


CMDSTATUS 


SHALL 


SHALL 


SHALL 


SHALL 



The following points should be noted: 

• A CMS shall support the server role for GET, PUT and DELETE. 

• A PS shall support the client role for GET, PUT and DELETE. 

• CMS and PS shall support client and server roles for CMDSTATUS. 

• All other behaviour is OPTIONAL. 

These requirements enforce provisioning data flows from the PS to the CMS and also ensure that the CMS is not 
required to push dynamic data changes (user adjustable call feature changes, etc.) back to the PS. 

The PS is able to read specific objects from the CMS. This use case is supported primarily to allow the PS to retrieve 
user call feature settings ("dynamic data") owned by the CMS. This is accomplished by reading specific PcspService 
objects from the CMS. 

Figure 5 displays all the required messaging roles. 



PS 



GET 



CMS 



GET Response 



PUT (Create or Modify) 



PUT Response 



DELETE 



DELETE Response 



CMDSTATUS 



CMDSTATUS Respone 



CMDSTATUS 



CMDSTATUS Response 



Figures: Required Messaging Flows 
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10.3 WSDL Document 



The PCSP interface is specified using Web Service Description Language 1.1. Just as with a Corba IDL, the WSDL 
interface definition specifies the remote methods on the interface, the arguments the methods accepts, the return values 
from the methods, and any interface specific data types that must be defined. Additionally, the WSDL definition also 
specifies the message encoding format (SOAP 1.1) and the transport binding (HTTP 1.1). 

The WSDL is fed into various Web Services toolkits, available for most operating systems and languages, to 
automatically generate client interface stubs, server skeletons, and SOAP marshalling support. 

PCSP clients and servers shall conform to this WSDL definition presented in annex D. 



1 1 Security 



The PCSP interface is secured using the IPSec ESP protocol in transport mode. Key management is implemented using 
IKE with pre-shared keys. This security infrastructure is already used at the CMS for various interfaces. See [3] for full 
details. 
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Annex A (normative): 
PCSP XML Schema 



*<?xml version="l . 0" encoding="UTF-8" ?> 
< ! - - 

IPCablecom CMS Subscriber/Service Provisioning (PCSP) schema. 

PCSP defines a messaging interface and an XML encoding format for objects 
transmitted over that interface. This schema defines the XML encoding syntax for 
the objects transmitted over the PCSP interface. 

Encodings for PcspService, PcspEndpoint , PcspMta, and PcspCms objects are specified. 

A PcspRelation encoding describes associations between objects. 

A PcspImportExport encoding is used to produce instance documents containing large numbers of 
objects . 
- - > 

<xs : schema targetNamespace="http : //www. cablelabs . com/Pcsp/IOl/schema" 

xmlns :xs="http : //www. w3 . org/2 001/XMLSchema" xmlns="http : //www. cablelabs . com/Pcsp/IOl/schema" 
elementFormDefault=" qualified" > 

< ! - - 

================= TYPE DEFINITIONS ===================== 



A non-empty string. 



<xs : simpleType name="nonEmptyString" > 

<xs : restriction base="xs : string" > 
<xs iminLength value="l"/> 

</xs : restriction> 
</xs : simpleType> 

< ! - - 

A Service ID. 

A non null string containing a "format" attribute {an enumeration) , which defaults to NSN. 

- - > 

<xs : complexType name="ServiceIdType" > 
<xs : simpleContent> 

<xs : extension base="nonEmptyString" > 

<xs : attribute name=" format" def ault="NSN" > 
<xs : simpleType> 

<xs : restriction base="xs : string" > 
<xs : enumeration value="NSN"/> 
<xs : enumeration value="E164"/> 
<xs : enumeration value="ENUM"/> 
<xs : enumeration value="URL"/> 
</xs : restriction> 
</xs : simpleType> 
</xs : attribute> 
</xs : extension> 
</xs : simpleContent> 
</xs : complexType > 

< ! - - 

A relation operation type. 

Used to indicate relation is being "added" or "deleted" . 

- - > 

<xs : simpleType name="RelationOpType" > 
<xs : restriction base="xs : string" > 
<xs : enumeration value="add"/> 
<xs : enumeration value= "delete "/> 
</xs : restriction> 
</xs : simpleType> 

< ! - - 

An enumeration of legal object "class" names. 

- - > 

<xs : simpleType name="classType" > 

<xs : restriction base="xs : string" > 

<xs : enumeration value=" PcspService "/> 
<xs : enumeration value=" PcspCms "/> 
<xs : enumeration value="PcspEndpoint"/> 
<xs : enumeration value=" PcspMta" /> 
</xs : restriction> 
</xs : simpleType> 

< ! - - 

A list of object keys. 
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<xs : complexType name="ListOf Keys" > 

<xs : sequence> 

<xs:element name="Key" type="xs : string" minOccurs="l" maxOccurs="unbounded"/> 

</xs : sequence> 
</xs : complexType > 
< ! - - 

Codec types . 

An enumeration that matches the PktcCodecType object from the 

IPCablecom Audio/Video Codecs Specification. 

This enumeration should be kept in sync with the aforementioned specification. 

For convenience, value definitions are repeated here. 



1 


other. 


2 


unknown . 


3 


G729 


4 


reserved 


5 


G729E 


6 


PCMU 


7 


G726-32 


8 


G728 


9 


PCMA 


10 


G726-16 


11 


G72S-24 


12 


G726-40 


13 


iLBC 


14 


BV-16 



In the case of the PcspEndpoint object, a codec value of 2 (unknown) shall be 
interpreted as "use the MTA's codec specification". 



<xs : simpleType name="codecType" > 

<xs : restriction base="xs : integer" > 



<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 
<xs 

</xs : restriction> 
</xs : simpleType> 



enumeration value= 
enumeration value= 
enumeration value= 
enumeration value= 
enumeration value= 
enumeration value= 
enumeration value= 
enumeration value= 
enumeration value= 
enumeration value= 
enumeration value= 
enumeration value= 
enumeration value= 
enumeration value= 



"/> 

"/> 

"/> 

"/> 

"/> 

"/> 

"/> 

8"/> 

9"/> 

1 " / > 

ll"/> 

12"/> 

13"/> 

14"/> 



Signalling protocol designations. 

PcspEndpoint employs "MtaDefault" to force use of the MTA's default protocol setting. 

- - > 

<xs : simpleType name="protocolType" > 
<xs : restriction base="xs : string" > 

<xs : enumeration value="MCGP 1.0 NCS 1.0"/> 
<xs : enumeration value="MtaDef ault"/> 
</xs : restriction> 
</xs : simpleType> 

< ! - - 

Numeric timezone designation per RFC 1123 [i.5] . 

- - > 

<xs : simpleType name="timezoneType" > 

<xs : restriction base="xs : string" > 

<xs: pattern value=" [\ + \-] \d{4 } "/> 

</xs : restriction> 
</xs : simpleType> 

< ! - - 

Local number PortingStatus 



not ported. 

ported in {owned by another TSP) 

ported out {loaned to another TSP) 



<xs : simpleType name="portingStatusType" > 
<xs : restriction base="xs : integer" > 
<xs : enumeration value="0"/> 
<xs : enumeration value="l"/> 
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<xs : enumeration value="2"/> 
</xs : restriction> 
</xs : simpleType> 



SUPPORTING ELEMENT DEFINITIONS 



Network announcement control . Contains . 
Language - per XML schema language type. 

Timezone - see previous definition. 

- - > 

<xs : element name = "Announcements" > 
<xs : complexType> 
<xs : sequence> 

<xs:element name= "Language" type="xs : language"/> 
<xs:element name="Timezone" type="timezoneType"/> 
</xs : sequence> 
</xs : complexType> 
</xs : element> 

< ! - - 

Interexchange carrier codes. Used to route off net regional, long distance, 
and international calls to specific carriers. 

PIC - Predesignated interexchange carrier {long distance) . 

LPIC - Predesignated intra-lata carrier 

IPIC - Predesignated international carrier 

- - > 

<xs : element name="InterExchange" > 
<xs : complexType> 
<xs : sequence> 

<xs:element name="PIC" type="xs : string"/> 
<xs:element name="LPIC" type="xs : string"/> 
<xs:element name="IPIC" type="xs : string"/> 
</xs : sequence> 
</xs : complexType> 
</xs : element > 

< ! - - 

Local Number Portability parameters. 

PortingStatus - see portingStatusType . 

LNPT - LNP trigger determines if number is in transition. 
false/0: no STP lookup required. 
true/1: STP lookup required to determine LRN of destination switch. 

- - > 

<xs: element name="LNP"> 
<xs : complexType> 
<xs : sequence> 

<xs:element name=" PortingStatus" type="portingStatusType"/> 
<xs:element name="LNPT" type="xs :boolean"/> 
</xs : sequence> 
</xs : complexType> 
</xs : element> 

< ! - - 

Vendor Extension element. 

Used within the PcspService, PcspCms, PcspMta, and PcspEndpoint objects to enable vendor 
extensions . 

Also used to extend the call feature list within the PcspService object. 

- - > 

<xs: element name= "Extension" > 
<xs : complexType> 
<xs : sequence> 

<xs : any namespace="##any" processContents=" strict" minOccurs=" 0" 
maxOccur s = " unbounded " / > 

</xs : sequence> 
</xs : complexType> 
</xs : element > 

< ! - - 

======================= Call Features. =========================== 



A service includes a list of call feature objects, each encoding one of the call features 
described in PKT-TR-VOIPBRF-ROl-000608 and PKT-TR-VOIPERF-ROl- 000831 . 
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Each call feature includes its "static" state data {owned by the PS) : 
Feature name {implicitly as the element name) , 
Subscribed/non subscribed state, 
Administrative state the feature. 

Many call features include just this information. 

Absence of a specific call feature implies the feature is not subscribed. 

The subscribed state is used to indicate that an 

explicitly listed call feature is not subscribed {an atypical case) . 

Several features extend the "static" parameter set with feature specific data. 

This feature specific data is typically configured by the user {via handset or by calling a 

The PCSP spec classifies the user adjustable data as "dynamic", meaning that it is owned 

by the CMS. Changes to the dynamic data in the CMS are not required to be pushed back to the 



Always - 

false/0: Subscriber may change forward-to number. 

true/1: Service provider {only) may change forward-to number 

- - > 

<xs: element name= "Always" type="xs : boolean" /> 

< ! - - 

ForwardTo - Service Id to which call will be forwarded. 
Note: empty strings are allowed. 

- - > 

<xs:element name =" ForwardTo" type="xs : string"/> 

< ! - - 

ListOf Serviceld - a list of Service Ids. 

- - > 

<xs : element name="ListOf Serviceld" > 
<xs : complexType> 
<xs : sequence> 

<xs:element name="ServiceId" type="xs : string" minOccurs=" 0" maxOccurs="unbounded"/> 
</xs : sequence> 
</xs : complexType> 
</xs : element> 

< ! - - 

ListOf SpeedDial - list of Service Ids / speed dial # pairs. 

Each pair contains a one or two digit speed dial number and its associated service id. 

- - > 

<xs: element name="SdPair" > 
<xs : complexType> 
<xs : sequence> 

<xs: element name="SdNum" > 
<xs : simpleType> 

<xs : restriction base="xs : integer" > 
<xs :minlnclusive value="0"/> 
<xs :maxlnclusive value="99"/> 
</xs : restriction> 
</xs : simpleType> 
</xs : element > 

<xs:element name=" Serviceld" type="xs : string"/> 
</xs : sequence> 
</xs : complexType> 
</xs : element > 

<xs : element name=" ListOf SpeedDial" > 
<xs : complexType> 
<xs : sequence> 

<xs:element ref="SdPair" minOccurs=" 0" maxOccurs="unbounded"/> 
</xs : sequence > 
</xs : complexType> 
</xs : element> 

< ! - - 

The definition of each of the supported call features. . . 

All call features can be considered in two parts. 

1. Common section containing the administrative state of the feature {the "static" data) . 

2. An optional section containing feature specific parameters, typically set by the end user 
{the "dynamic" data) . 

- - > 

< ! - - 

The "base object" for all call features, containing: 

Subscribed - 

0/false: feature is not subscribed 
1/true: feature is subscribed. 
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UsageBilling - 

0/false: do not generate billing records on feature usage 
1/true: generate billing records on feature usage. 

AdminStatus - 

0: feature is suspended by service provider. 
1: feature is enabled by service provider. . 

In general, presence of a call feature implies that it is subscribed. 

The Subscribed flag is supported for the atypical case of wanting to 

indicate that an explicitly listed call feature is not subscribed. 

- - > 

<xs : complexType name="CfBase" > 
<xs : sequence> 

<xs: element name=" Subscribed" type="xs : boolean" /> 

<xs:element name="UsageBilling" type="xs : boolean" minOccurs = "0"/> 
<xs : element name= "AdminStatus " > 
<xs : simpleType> 

<xs : restriction base="xs : int" > 
<xs : enumeration value="0"/> 
<xs : enumeration value="l"/> 
</xs : restriction> 
</xs : simpleType> 
</xs : element > 
</xs : sequence> 
</xs : complexType > 

< ! - - 

"CND" Calling Number Delivery 

- - > 

<xs: element name="Cf CND" > 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="CfBase"/> 
</xs : complexContent> 
</xs : complexType> 
</xs : element> 

< ! - - 

"CNAM": Calling Name Delivery 

- - > 

<xs: element name="Cf CNAM" > 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="CfBase"/> 
</xs : complexContent> 
</xs : complexType> 
</xs : element> 

< ! - - 

"CIDCW": Calling Identity Delivery on Call Waiting 

- - > 

<xs: element name="Cf CIDCW" > 
<xs : complexType > 

<xs : complexContent> 

<xs : extension base="CfBase"/> 
</xs : complexContent> 
</xs : complexType> 
</xs : element> 

< ! - - 

"CW" : Call Waiting 

- - > 

<xs:element name="CfCW"> 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="CfBase"/> 
</xs : complexContent> 
</xs : complexType > 
</xs : element> 

< ! - - 

"CCW": Cancel Call Waiting {*70) 

- - > 

<xs: element name="Cf CCW" > 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="CfBase"/> 
</xs : complexContent> 
</xs : complexType > 
</xs : element> 
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"CFV" : Call Forwarding Variable and Usage- Sensitive Call Forwarding {*72/*73) 

Extends CfBase with the following: 

Active - 

0/false: user has deactivated feature {*73) . 
1/true: user has activated feature {*72) . 

- - > 

<xs: element name="Cf CFV" > 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="CfBase" > 
<xs : sequence> 

<xs: element name="UserParams" minOccurs=" 0" > 
<xs : complexType> 
<xs : sequence> 

<xs:element name="Active" type="xs :boolean"/> 
</xs : sequence> 
</xs : complexType> 
</xs : element > 
</xs : sequence> 
</xs : extension> 
</xs : complexContent> 
</xs : complexType> 
</xs : element> 

< ! - - 

"AR" : Automatic Recall {*S9) 

- - > 

<xs: element name="CfAR"> 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="CfBase"/> 
</xs : complexContent> 
</xs : complexType> 
</xs : element> 

< ! - - 

"AC": Automatic Callback {*66) 

- - > 

<xs: element name="CfAC"> 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="CfBase"/> 
</xs : complexContent> 
</xs : complexType> 
</xs : element> 

< ! - - 

"VMWI": Visual Message Waiting Indicator 

Extends CfBase with the following: 
Indicator Type - 



None . 

Stutter Dial tone Only 
Message Lamp Only 

Both Stutter Dial tone and Message Lamp 
- - > 

<xs: element name="CfVMWI" > 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="CfBase" > 
<xs : sequence> 

<xs: element name="UserParams" minOccurs=" 0" > 
<xs : complexType> 
<xs : sequence> 

<xs: element name="Type"> 
<xs : simpleType> 

<xs : restriction base="xs : int" > 
<xs : enumeration value="0"/> 
<xs : enumeration value="l"/> 
<xs : enumeration value="2"/> 
<xs : enumeration value="3"/> 
</xs : restriction> 
</xs : simpleType> 
</xs : element> 
</xs : sequence> 
</xs : complexType> 
</xs : element > 
</xs : sequence> 
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</xs : extension> 
</xs : complexContent> 
</xs : complexType> 
</xs : element> 

< ! - - 

"COT": Customer Originated Trace {*57) 

- - > 

<xs: element name="Cf COT" > 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="CfBase"/> 
</xs : complexContent> 
</xs : complexType> 
</xs : element > 

< ! - - 

"TWC" : Three-Way Calling / Usage-Sensitive Three-Way Calling {*71) 

- - > 

<xs: element name="CfTWC" > 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="CfBase"/> 
</xs : complexContent> 
</xs : complexType> 
</xs : element > 

< ! - - 

"RACF" : Remote Activation of Call Forwarding 

- - > 

<xs: element name="CfRACF" > 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="CfBase"/> 
</xs : complexContent> 
</xs : complexType> 
</xs : element > 

< ! - - 

"OCAA" : Outside Calling Area Alerting 

- - > 

<xs: element name="CfOCAA" > 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="CfBase"/> 
</xs : complexContent> 
</xs : complexType> 
</xs : element> 

< ! - - 

"CIES" : Calling Identity with Enhanced Screening 

- - > 

<xs: element name="Cf CIES" > 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="CfBase"/> 
</xs : complexContent> 
</xs : complexType> 
</xs : element> 

< ! - - 

"ACR" : Anonymous Call Rejection (*11 / *87) 

Extends CfBase with the following: 

Active - 

0/false: user has deactivated feature {*87) . 
1/true: user has activated feature (*11) . 

- - > 

<xs: element name="CfACR" > 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="CfBase" > 
<xs : sequence> 

<xs: element name="UserParams" minOccurs=" 0" > 
<xs : complexType> 
<xs : sequence> 

<xs:element name="Active" type="xs : boolean" /> 
</xs : sequence> 
</xs : complexType> 
</xs : element > 
</xs : sequence> 
</xs : extension> 
</xs : complexContent> 
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</xs : complexType> 
</xs : element> 

< ! - - 

"AC-R" : Automatic Callback - Restrict 

- - > 

<xs : element name="CfACRestrict" > 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="CfBase"/> 
</xs : complexContent> 
</xs : complexType> 
</xs : element > 

< ! - - 

"ACB" : Automatic Recall Blocking 

- - > 

<xs: element name="Cf ACB" > 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="CfBase"/> 
</xs : complexContent> 
</xs : complexType> 
</xs : element > 

< ! - - 

"CIDB" Calling Identity Delivery Blocking {*67 / *82) . 

Extends CfBase with the following: 

Flag - 

"PUBLIC": deliver Caller ID info 
"ANONYMOUS": do not deliver Caller ID info. 

- - > 

<xs: element name="Cf CIDB" > 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="CfBase" > 
<xs : sequence> 

<xs: element name="UserParams" minOccurs=" 0" > 
<xs : complexType> 
<xs : sequence> 

<xs: element name="Flag"> 
<xs : simpleType> 

<xs : restriction base="xs : string" > 

<xs : enumeration value=" PUBLIC" /> 
<xs : enumeration value= "ANONYMOUS "/> 
</xs : restriction> 
</xs : simpleType> 
</xs : element> 
</xs : sequence> 
</xs : complexType> 
</xs : element> 
</xs : sequence> 
</xs : extension> 
</xs : complexContent> 
</xs : complexType> 
</xs : element> 

< ! - - 

"CFBL" Call Forwarding Busy Line { *68 / *40 / *88 ) . 

Extends CfBase with the following "dynamic", user 
adjustable parameters {owned by the CMS) . 

Active - 

0/false: user has deactivated feature {*88) . 
1/true: user has activated feature {*68/*40) . 

Always - see previous definition. 

ForwardTo - see previous definition. 

- - > 

<xs: element name="Cf CFBL" > 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="CfBase" > 
<xs : sequence> 

<xs: element name="UserParams" minOccurs=" 0" > 
<xs : complexType> 
<xs : sequence> 

<xs: element name= "Active" type="xs : boolean" /> 
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<xs:element ref ="Always"/> 

<xs:element ref ="ForwardTo" minOccurs=" 0"/> 
</xs : sequence> 
</xs : complexType> 
</xs : element> 
</xs : sequence> 
</xs : extension> 
</xs : complexContent> 
</xs : complexType> 
</xs : element> 

< ! - - 

"CFDA" Call Forwarding Don't Answer {*68 / *42 / *88) 

Extends CfBase with the following "dynamic", user 
adjustable parameters {owned by the CMS) : 

Active - 

0/false: user has deactivated feature {*88) . 
1/true: user has activated feature {*68/*42) . 

Always - see previous definition. 

RingPeriod - number of ringing cycles after which forwarding is activated. 

ForwardTo - see previous definition. 

- - > 

<xs: element name="Cf CFDA" > 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="CfBase" > 
<xs : sequence> 

<xs: element name="UserParams" minOccurs="0" > 
<xs : complexType> 
<xs : sequence> 

<xs:element name="Active" type="xs :boolean"/> 
<xs: element ref = "Always "/> 

<xs:element name="RingPeriod" type="xs : int"/> 
<xs: element ref =" ForwardTo" minOccurs="0"/> 
</xs : sequence> 
</xs : complexType> 
</xs : element > 
</xs : sequence> 
</xs : extension> 
</xs : complexContent> 
</xs : complexType> 
</xs : element> 

< ! - - 

"CFC" Call Forwarding Combination 

Extends CfBase with the following "dynamic", user 
adjustable parameters {owned by the CMS) : 

Active - 

0/false: user has deactivated feature {*88) . 
1/true: user has activated feature {*68) . 

Always - see previous definition. 

RingPeriod - number of ringing cycles after which forwarding is activated. 

ForwardTo - see previous definition. 

- - > 

<xs: element name="Cf CFC" > 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="CfBase" > 
<xs : sequence> 

<xs: element name="UserParams" minOccurs=" 0" > 
<xs : complexType> 
<xs : sequence> 

<xs:element name="Active" type="xs :boolean"/> 
<xs: element ref = "Always "/> 

<xs:element name="RingPeriod" type="xs : int"/> 
<xs:element ref ="ForwardTo" minOccurs="0"/> 
</xs : sequence> 
</xs : complexType> 
</xs : element > 
</xs : sequence> 
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</xs : extension> 
</xs : complexContent> 
</xs : complexType> 
</xs : element > 

< ! - - 

"SCF" Selective Call Forwarding {*63/*83) . 

Extends CfBase with the following "dynamic", user 
adjustable parameters {owned by the CMS) : 

Active - 

0/false: user has deactivated feature {*83) . 
1/true: user has activated feature {*63) . 

ListOf Serviceld - list of service identifiers that will be forwarded. See previous element 
definition. 

ForwardTo - the service to which to forward. See previous element definition. 

- - > 

<xs: element name="Cf SCF" > 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="CfBase" > 
<xs : sequence> 

<xs: element name="UserParams" minOccurs=" 0" > 
<xs : complexType> 
<xs : sequence> 

<xs: element name= "Active" type="xs : boolean" /> 
<xs:element ref="ListOf Serviceld" minOccurs=" 0"/> 
<xs: element ref=" ForwardTo" minOccurs="0"/> 
</xs : sequence> 
</xs : complexType> 
</xs : element > 
</xs : sequence> 
</xs : extension> 
</xs : complexContent> 
</xs : complexType> 
</xs : element> 

< ! - - 

"SCA" Selective Call Acceptance {*64 / *84 ) . 

Extends CfBase with the following "dynamic", user 
adjustable parameters {owned by the CMS) : 

Active - 

0/false: user has deactivated feature {*84) . 
1/true: user has activated feature {*66) . 

ListOf Servicelds - list of service identifiers that will be accepted. See previous element 
definition. 

- - > 

<xs: element name="Cf SCA" > 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="CfBase" > 
<xs : sequence> 

<xs: element name="UserParams" minOccurs=" 0" > 
<xs : complexType> 
<xs : sequence> 

<xs: element name= "Active" type="xs : boolean" /> 
<xs:element ref="ListOf Serviceld" minOccurs=" 0"/> 
</xs : sequence > 
</xs : complexType> 
</xs : element > 
</xs : sequence> 
</xs : extension> 
</xs : complexContent> 
</xs : complexType> 
</xs : element> 

< ! - - 

"SCR" Selective Call Rejection {*60 / *80 ) . 

Extends CfBase with the following "dynamic", user 
adjustable parameters {owned by the CMS) : 

Active - 

0/false: user has deactivated feature {*80) . 
1/true: user has activated feature {*60) . 
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ListOf Servicelds - list of service identifiers that will be rejected. See previous element 
definition. 
- - > 

<xs: element name="Cf SCR" > 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="CfBase" > 
<xs : sequence> 

<xs: element name="UserParams" minOccurs=" 0" > 
<xs : complexType> 
<xs : sequence> 

<xs:element name="Active" type="xs :boolean"/> 
<xs: element ref = "ListOf Serviceld" minOccurs="0"/> 
</xs : sequence> 
</xs : complexType> 
</xs : element> 
</xs : sequence> 
</xs : extension> 
</xs : complexContent> 
</xs : complexType> 
</xs : element > 
< ! - - 

"DRCW" Distinctive Ringing/Call Waiting {*61 / *81) 

Extends CfBase with the following "dynamic", user 
adjustable parameters {owned by the CMS) : 

Active - 

0/false: user has deactivated feature {*81) . 
1/true: user has activated feature {*61) . 



ring 
definition. 



ListOf Servicelds - list of incoming service identifiers that will receive the distinctive 
treatment {vs. standard power ring or call waiting tone) . See previous element 



<xs: element name="CfDRCW" > 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="CfBase" > 
<xs : sequence> 

<xs: element name="UserParams" minOccurs=" 0" > 
<xs : complexType> 
<xs : sequence> 

<xs: element name= "Active" type="xs : boolean" /> 
<xs:element ref ="ListOf Serviceld" minOccurs="0"/> 
</xs : sequence> 
</xs : complexType> 
</xs : element> 
</xs : sequence> 
</xs : extension> 
</xs : complexContent> 
</xs : complexType> 
</xs : element> 
< ! - - 

"SPCALL" Speed Calling {*74 / *75) 

Extends CfBase with the following "dynamic", user 
adjustable parameters {owned by the CMS) : 

ListOf SpeedDial - see previous element definition. 
- - > 

<xs: element name="Cf SPCALL" > 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="CfBase" > 
<xs : sequence> 

<xs: element name="UserParams" minOccurs=" 0" > 
<xs : complexType> 
<xs : sequence> 

<xs : element ref =" ListOf SpeedDial" /> 
</xs : sequence> 
</xs : complexType> 
</xs : element > 
</xs : sequence> 
</xs : extension> 
</xs : complexContent> 
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</xs : complexType> 
</xs : element> 

< ! - - 

"RDA" Residence Distinctive Alerting Service. 

- - > 

<xs: element name="CfRDA" > 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="CfBase"/> 
</xs : complexContent> 
</xs : complexType> 
</xs : element> 

< ! - - 

"LSR" Line Service Restriction. 

Extends CfBase with the following "dynamic", user 
adjustable parameters {owned by the CMS) : 

BlkDomLongDist - block for outgoing domestic long distance calls. 

0/false: not blocked. 

1/true: blocked. 
BlklntlLongDist - block for outgoing international long distance calls. 

0/false: not blocked. 

1/true: blocked. 
BlkPayPerCall - block for outgoing pay per calls {900/97S) . 

0/false: not blocked. 

1/true: blocked. 
BlkOperatorAssist - block for outgoing operator assisted calls. 

0/false: not blocked. 

1/true: blocked. 
BlkDirAssist - block for outgoing directory assistance calls. 

0/false: not blocked. 

1/true: blocked. 
BlkTollFree - block for outgoing toll free calls. 

0/false: not blocked. 

1/true: blocked. 
Active - 

0/false: user has deactivated feature {*82) . 

1/true: user has activated feature. 
PIN - code to enter to deactivate blocking 

ServiceList - list of service identifiers for domestic long distance calls that are always 
allowed. 

- - > 

<xs: element name="CfLSR" > 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="CfBase" > 
<xs : sequence> 

<xs: element name="UserParams" minOccurs=" 0" > 
<xs : complexType> 
<xs : sequence> 

<xs:element name="BlkDomLongDist" type="xs :boolean" 



minOccurs=" 0"/> 
minOccurs=" 0"/> 
minOccurs=" 0"/> 
minOccurs=" 0"/> 
minOccurs=" 0"/> 



<xs:element name="BlkIntLongDist" type="xs : boolean" 

<xs:element name="BlkPayPerCall" type="xs : boolean" 

<xs:element name="BlkOperatorAssist" type="xs : boolean" 

<xs:element name="BlkDirAssist" type="xs :boolean" 



<xs:element name="BlkTollFree" type="xs : boolean" minOccurs=" 0"/> 
<xs: element name="PIN" type="xs : string" minOccurs ="0"/> 
<xs:element name="Active" type="xs :boolean"/> 
<xs:element ref ="ListOf Serviceld" minOccurs="0"/> 
</xs : sequence> 
</xs : complexType> 
</xs : element> 
</xs : sequence > 
</xs : extension> 
</xs : complexContent> 
</xs : complexType> 
</xs : element> 
< ! - - 

"DND" Do Not Disturb 

Extends CfBase with the following "dynamic", user 
adjustable parameters {owned by the CMS) : 
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Active - 

0/false: user has deactivated feature. 
1/true: user has activated feature. 

WeekDayStartTodl - week day start time for DND . 
WeekDayStopTodl - week day stop time for DND. 
WeekDayStartTod2 - week day start time for DND. 
WeekDayStopTod2 - week day stop time for DND. 
WeekEndStartTodl - week end start time for DND. 
WeekEndStopTodl - week end stop time for DND. 
WeekEndStartTod2 - week end start time for DND. 
WeekEndStopTod2 - week end stop time for DND. 

- - > 

<xs: element name="CfDND" > 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="CfBase" > 
<xs : sequence> 

<xs: element name="UserParams" minOccurs="0" > 
<xs : complexType> 
<xs : sequence> 

<xs:element name="Active" type="xs :boolean"/> 

<xs:element name="WdStartTodl" type="xs : time" minOccurs=" 0"/> 
<xs:element name="WdStopTodl" type="xs : time" minOccurs="0"/> 
<xs:element name="WdStartTod2" type="xs : time" minOccurs=" 0"/> 
<xs:element name="WdStopTod2" type="xs : time" minOccurs=" 0"/> 
<xs:element name="WeStartTodl" type="xs : time" minOccurs=" 0"/> 
<xs:element name="WeStopTodl" type="xs : time" minOccurs="0"/> 
<xs:element name="WeStartTod2" type="xs : time" minOccurs=" 0"/> 
<xs:element name="WeStopTod2" type="xs : time" minOccurs="0"/> 
</xs : sequence> 
</xs : complexType> 
</xs : element > 
</xs : sequence> 
</xs : extension> 
</xs : complexContent> 
</xs : complexType> 
</xs : element> 

< ! - - 

"COC" Curfew on Calls. 

Extends CfBase with the following "dynamic", user 
adjustable parameters (owned by the CMS) : 

Active - 

0/false: user has deactivated feature. 
1/true: user has activated feature. 

StartTod - start time for COC. 
StopTod - stop time for COC. 

ServiceList - list of service identifiers for incoming and outgoing services which are 
allowed to bypass the NSA. 

- - > 

<xs: element name="Cf COC" > 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="CfBase" > 
<xs : sequence> 

<xs: element name="UserParams" minOccurs=" 0" > 
<xs : complexType> 
<xs : sequence> 

<xs:element name="Active" type="xs :boolean"/> 
<xs:element name="StartTod" type="xs : time"/> 
<xs:element name=" StopTod" type="xs : time"/> 
<xs:element ref ="ListOf Serviceld" minOccurs=" 0"/> 
</xs : sequence> 
</xs : complexType> 
</xs : element > 
</xs : sequence> 
</xs : extension> 
</xs : complexContent> 
</xs : complexType> 
</xs : element> 

< ! - - 

"NSA" No Solicitation Announcement 

Extends CfBase with the following "dynamic", user 
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adjustable parameters {owned by the CMS) : 

Active - 

0/false: user has deactivated feature. 
1/true: user has activated feature. 

StartTod - start time for COC. 
StopTod - stop time for COC. 

ServiceList - list of service identifiers for incoming and outgoing services which are 
allowed to bypass the NSA. 
- - > 

<xs: element name="CfNSA" > 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="CfBase" > 
<xs : sequence> 

<xs: element name="UserParams" minOccurs="0" > 
<xs : complexType> 
<xs : sequence> 

<xs: element name= "Active" type="xs : boolean" /> 
<xs:element name=" StartTod" type="xs : time"/> 
<xs:element name="StopTod" type="xs : time"/> 
<xs:element ref ="ListOf Serviceld" minOccurs=" 0"/> 
</xs : sequence> 
</xs : complexType> 
</xs : element> 
</xs : sequence> 
</xs : extension> 
</xs : complexContent> 
</xs : complexType> 
</xs : element> 



A list of call features. The list may contain at most 1 of each of the 
features outlined above, along with any vendor extension call features. 

- - > 

<xs : element name="ListOf CallFeatures" > 
<xs : complexType> 
<xs : all> 



<xs: element ref= 
<xs: element ref= 
<xs: element ref= 
<xs: element ref= 
<xs: element ref= 
<xs: element ref= 
<xs: element ref= 
<xs: element ref= 
<xs: element ref= 
<xs: element ref= 
<xs: element ref= 
<xs: element ref= 
<xs: element ref= 
<xs: element ref= 
<xs: element ref= 
<xs: element ref= 
<xs: element ref= 
<xs: element ref= 
<xs: element ref= 
<xs: element ref= 
<xs: element ref= 
<xs: element ref= 
<xs: element ref= 
<xs: element ref= 
<xs: element ref= 
<xs: element ref= 
<xs: element ref= 
<xs: element ref= 
<xs: element ref= 
<xs: element ref= 
<xs: element ref= 
<xs: element ref= 
</xs : all> 
</xs : complexType> 
</xs : element> 



CfCND" minOccurs="0"/> 
CfCNAM" minOccurs="0"/> 
CfCIDCW" minOccurs="0"/> 
CfCW" minOccurs="0"/> 
CfCCW" minOccurs="0"/> 
CfCFV" minOccurs="0"/> 
CfAR" minOccurs="0"/> 
CfAC" minOccurs="0"/> 
CfVMWI" minOccurs="0"/> 
CfCOT" minOccurs="0"/> 
CfTWC" minOccurs="0"/> 
CfRACF" minOccurs="0"/> 
CfOCAA" minOccurs="0"/> 
CfCIES" minOccurs="0"/> 
CfACR" minOccurs="0"/> 
CfACRestrict" minOccurs=" " /> 
CfACB" minOccurs="0"/> 
CfCIDB" minOccurs="0"/> 
CfCFBL" minOccurs="0"/> 
CfCFDA" minOccurs="0"/> 
CfCFC" minOccurs="0"/> 
CfSCF" minOccurs="0"/> 
CfSCA" minOccurs="0"/> 
CfSCR" minOccurs="0"/> 
CfDRCW" minOccurs="0"/> 
CfSPCALL" minOccurs="0"/> 
CfRDA" minOccurs="0"/> 
CfLSR" minOccurs="0"/> 
CfDND" minOccurs="0"/> 
CfCOC" minOccurs="0"/> 
CfNSA" minOccurs="0"/> 
Extension" minOccurs=" 0"/> 



MAIN OBJECT DEFINITIONS 



There are 6 encodings defined in the PCSP schema. 
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The 4 main object encodings: 

PcspCms - a CMS. A collection of Services and Endpoints. 

PcspService - represents a phone number, its configuration, and call features. 
PcspMta - represents a physical MTA and its configuration. A collection of Endpoints. 
PcspEndpoint - represents an Endpoint on an MTA. 

A PcspRelation object. This object encodes the associations between objects. 

A PcspImportExport object. This is used to produce a bulk loading file for the CMS. 

- - > 

< ! - - 

PcspRelation. 

The relation object specifies inter-object associations between the PcspCms, 
PcspService, PcspEndpoint, and PcspMta objects. 

The "relOp" attribute specified if the relation is being added or deleted. 

- - > 

<xs : element name=" PcspRelation" > 
<xs : complexType> 
<xs : sequence> 

<xs:element name="Classl" type="classType"/> 
<xs:element name="Key" type="xs : string" /> 
<xs:element name="Class2" type="classType"/> 
<xs:element name="ListOf Keys" type="ListOf Keys"/> 
</xs : sequence> 

<xs : attribute name="relOp" type="RelationOpType" use=" required" /> 
</xs : complexType> 
</xs : element > 

< ! - - 

The PcspCms object. 

This object maintains associations between Endpoints, Services, and their managing CMSs. 
Contents . . . 

CmsFqdn - FQDN uniquely identifying this CMS. 

- - > 

<xs: element name= " PcspCms " > 
<xs : complexType> 
<xs : sequence> 

<xs:element name =" CmsFqdn" type="nonEmptyString"/> 
<xs:element ref ="Extension" minOccurs="0"/> 
</xs : sequence> 
</xs : complexType> 
</xs : element> 

< ! - - 

The PcspEndpoint object. 

An endpoint is a physical port on a MTA/Gateway. 

Contents . . . 

Endpointid - Uniquely identifies this endpoint. Format per 

"IPCablecom Network Based Call Signalling Protocol Specification". 
Example : "aaln/l@mta01 . cablelabs . com" 

AdminStatus - 

0: endpoint is disconnected 

1: normal - endpoint is in service 

2: test mode - endpoint is under test. 

Protocol - optional override for MTA protocol setting. 

Codec - optional override for MTA codec setting. 

IPSecControl - optional override for the MTA IPSecControl setting. 

- - > 

<xs : element name=" PcspEndpoint" > 
<xs : complexType> 
<xs : sequence> 

<xs:element name="EndpointId" type="nonEmptyString"/> 
<xs : element name= "AdminStatus " > 
<xs : simpleType> 

<xs : restriction base="xs : integer" > 
<xs : enumeration value="0"/> 
<xs : enumeration value="l"/> 
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<xs : enumeration value="2"/> 
</xs : restriction> 
</xs : simpleType> 
</xs : element > 

<xs:element name=" Protocol" type="protocolType" minOccurs="0"/> 
<xs: element name=" Codec" type="codecType" minOccurs="0"/> 
<xs:element name="IPSecControl" type="xs : boolean" minOccurs=" 0"/> 
<xs: element ref=" Extension" minOccurs="0"/> 
</xs : sequence> 
</xs : complexType> 
</xs : element> 
< ! - - 

The PcspMta object. 

A Media Terminal Adapter aggregates one or more endpoints {physically contained within the 
Contents . . . 



MtaFqdn - MTA's FQDN, uniquely identifying this MTA. 
MtaPort - MTA's NCS listening port {default: 2427) 

CmtsFqdn - FQDN of controlling CMTS . CMS needs this to establish MTA DQoS with correct CMTS . 
MtaProfile - MTA Profile Name - Optional; An MTA Profile Indicator identifiable by the CMS. 
Timezone - within which this MTA is physically located. Optional; If present overrides the CMS 
default setting for the time zone. As per RFC 1123 numeric timezone format. 

Protocol - Optional; If present it must be set to "MGCP 1.0 NCS 1.0". This is the default for all 
contained endpoints. 

Codec - Optional; If present it is the default for all contained endpoints. 
IPSecControl - Optional; NCS IPSec Control Flag {default = True; IPSec enabled) . 
- - > 

<xs: element name="PcspMta" > 
<xs : complexType> 
<xs : sequence> 

<xs:element name= "MtaFqdn" type="nonEmptyString"/> 
<xs:element name="ListenPort" type="xs : int" minOccurs=" 0"/> 
<xs:element name="CmtsFqdn" type="xs : string"/> 

<xs:element name="MtaProf ile" type="xs : string" minOccurs=" 0"/> 
<xs:element name=" Timezone" type="timezoneType" minOccurs=" 0"/> 
<xs:element name=" Protocol" type="protocolType" minOccurs=" 0"/> 
<xs:element name="Codec" type="codecType" minOccurs="0"/> 
<xs:element name=" IPSecControl" type="xs : boolean" minOccurs=" 0"/> 
<xs:element ref ="Extension" minOccurs="0"/> 
</xs : sequence> 
</xs : complexType> 
</xs : element> 
< ! - - 

The PcspService object. 

Contents . . . 

Serviceld - unique identifier for the service. 

AdminStatus - 

0: suspended {i.e. bill not paid) . 
1: enabled {normal state) . 
2: number has changed. 
3: out of service. 
4 : unassigned. 



service . 



calls . 



Billingld - An telephone number identifying another service to be billed instead of this 

Externalld - an arbitrary string used to carry such data as subscriber ID, etc. 

IsPrimary - With multiple services provisioned upon an endpoint, one service MUST 
have this flag set to indicate the default service to use for outgoing 



false/0: this service is not a primary service. 
true/1: this service is a primary service. 

PrimaryRing - Primary Ringing Pattern ID. Index into MTA cadence table, selecting ring pattern for 
this service. Optional if the "Is Primary" flag is set to False. If not present, the CMS must use 
its normal ring pattern 

DisplayName - Used for Call Name Delivery feature {CNAM) 

DisplayNumber - Used for Call Number Delivery feature {CND) 
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Password - various call features require a password before any alterations are 



permitted. 



Network announcement control. See previous definition. Optional; if not present the CMS must use its 
default settings. 

Interexchange codes and Local Number Portability settings. See previous definitions. Optional; if 
not present the CMS must not assign any inter- exchange codes to the service. 

Call features. See previous definitions. 

- - > 

<xs : element name="PcspService" > 
<xs : complexType> 
<xs : sequence> 

<xs:element name="ServiceId" type="ServiceIdType"/> 
<xs : element name= " AdminStatus " > 
<xs : simpleType> 

<xs : restriction base="xs : integer" > 
<xs : enumeration value="0"/> 
<xs : enumeration value="l"/> 
<xs : enumeration value="2"/> 
<xs : enumeration value="3"/> 
<xs : enumeration value="4"/> 
</xs : restriction> 
</xs : simpleType> 
</xs : element > 

<xs:element name="BillingId" type="ServiceIdType"/> 
<xs:element name="ExternalId" type="xs : string"/> 
<xs:element name="IsPrimary" type="xs :boolean"/> 
<xs:element name="PrimaryRing" type="xs : string" minOccurs="0"/> 
<xs:element name="DisplayName" type="xs : string" /> 
<xs: element name="DisplayNumber" type="xs : string" /> 
<xs:element name=" Password" type="xs : string"/> 
<xs:element ref=" Announcements" minOccurs="0"/> 
<xs:element ref ="InterExchange" minOccurs=" 0"/> 
<xs:element ref="LNP"/> 
<xs : element ref ="ListOf CallFeatures"/> 
<xs:element ref ="Extension" minOccurs="0"/> 
</xs : sequence> 
</xs : complexType> 
</xs : element> 
< ! - - 

Import/Export file format. 

Used to transfer one or more objects and relations between PS/CMS. 

NOTE: PcspCms is not included. There is currently no reason for a CMS to obtain 
its own CMS object from the PS. 

- - > 

<xs : element name="PcspImportExport" > 
<xs : complexType> 

<xs:choice minOccurs="0" maxOccurs= " unbounded" > 
<xs : element ref ="PcspService"/> 
<xs : element ref ="PcspEndpoint"/> 
<xs:element ref ="PcspMta"/> 
<xs : element ref ="PcspRelation"/> 
</xs : choice> 
</xs : complexType> 
</xs : element > 
</xs : schema> 



£75/ 



37 ETSITS 103 161-17 V1. 1.1 (2011-04) 



Annex B (informative): 
Sample Entity Encodings 

B.1 PcspService Object Example 

<?xml version="l . 0" encoding="UTF-8" ?> 
< ! - - 

Example Service object encoding. 

Default and "pcsp" namespace is set to PcspIOl. 

"pcsp" namespace is a convenience, allowing vendor extensions 

to reference elements from the main PCSP schema. 

- - > 

< PcspService xmlns = "http : //www. cablelabs . com/ Pcsp/ 1 01/ schema" 

xmlns :pcsp="http : //www. cablelabs . com/Pcsp/IOl/schema" xmlns :xsi = "http : //www.w3 . org/2 1/XMLSchema- 
instance" xsi :noNamespaceSchemaLocation=" PcspIOl .xsd" > 
< ! - - 

A sample Service object. 
- - > 

<ServiceId format="NSN" >9785551212</Serviceld> 
<AdminStatus>l</AdminStatus> 
<BillingId>97855500 00</BillingId> 
<ExternalId>01234 5S78 9</ExternalId> 
<IsPrimary>true</IsPrimary> 

<PrimaryRing>IndexIntoCadenceTable</PrimaryRing> 
<DisplayName>John Q Public</DisplayName> 
<DisplayNumber> (978) -555-1212</DisplayNumber> 
<Password>4 5hjg3 j 6gkg6h54 j 6gkj3g6</Password> 
<Announcements> 

<Language>EN< /Language > 
<Timezone>+05 0</Timezone> 
< /Announcement s > 
<InterExchange> 

<PIC>0123</PIC> 
<LPIC>0123</LPIC> 
<IPIC>0123</IPIC> 
< / InterExchange> 
<LNP> 

<PortingStatus>0</PortingStatus> 
<LNPT>0</LNPT> 
</LNP> 

<ListOfCallFeatures> 
<CfCND> 

<Subscribed>true</Subscribed> 
<AdminStatus>l</AdminStatus> 
</CfCND> 
<CfCIDB> 

<Subscribed>0</Subscribed> 

<AdminStatus>l</AdminStatus> 

<UserParams> 

<Flag>PUBLIC</Flag> 
</UserParams> 
</CfCIDB> 
<CfCFBL> 

<Subscribed>true</Subscribed> 

<AdminStatus>l</AdminStatus> 

<UserParams> 

<Active>true</Active> 
<Always > < /Always > 

<ForwardTo>9785551212</ForwardTo> 
</UserParams> 
</CfCFBL> 
<CfSPCALL> 

<Subscribed>0</Subscribed> 

<AdminStatus>l</AdminStatus> 

<UserParams> 

<ListOfSpeedDial> 
<SdPair> 

<SdNum>l</SdNum> 

<ServiceId>978 55512 12 </ServiceId> 
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</SdPair> 
<SdPair> 

<SdNum>3</SdNum> 

<ServiceId>97855510 0</ServiceId> 
</SdPair> 
</ListOfSpeedDial> 
</UserParams> 
</CfSPCALL> 
<CfRDA> 

<Subscribed>l</Subscribed> 
<AdminStatus>l</AdminStatus> 
</CfRDA> 
<CfLSR> 

<Subscribed>l</Subscribed> 

<AdminStatus>l</AdminStatus> 

<UserParams> 

<BlkDomLongDist>l</BlkDomLongDist> 

<BlkIntLongDist>l</BlkIntLongDist> 

<BlkPayPerCall>l</BlkPayPerCall> 

<BlkOperatorAssist>l</BlkOperatorAssist> 

<BlkDirAssist>l</BlkDirAssist> 

<BlkTollFree>l</BlkTollFree> 

<ListOf Serviceld> 

<ServiceId>98955510 01</ServiceId> 
<ServiceId>98 95 5 510 02</ServiceId> 
<ServiceId>98 95 551003 </ServiceId> 
< /Li stOf Service Id> 
< /UserParams > 
</CfLSR> 
<CfDND> 

<Subscribed>l</Subscribed> 

<AdminStatus>l</AdminStatus> 

<UserParams> 

<Active>true</Active> 

<WdStartTodl>00 : 00 : 00+05 : 00</WdStartTodl> 
<WdStopTodl>06 : 00 : 00+05 : 00</WdStopTodl> 
<WdStartTod2>18 : 00 : 00+05 : 00</WdStartTod2> 
<WdStopTod2>2 : 00 : 00+05 : 00</WdStopTod2> 
<WeStartTodl>00 : 00 : 00+05 : 00</WeStartTodl> 
<WeStopTodl>09 : 00 : 00+05 : 00</WeStopTodl> 
<WeStartTod2>18 : 00 : 00+05 : 00</WeStartTod2> 
<WeStopTod2>20 : 00 : 00+05 : 00</WeStopTod2> 
< /UserParams > 
</CfDND> 
<CfCOC> 

<Subscribed>l</Subscribed> 

<AdminStatus>l</AdminStatus> 

<UserParams> 

<Active>true</Active> 
<StartTod>00 : 00 : 00+05 : 00</StartTod> 
<StopTod>06 : 00 : 00+05 : 00</StopTod> 
<ListOf Serviceld> 

<ServiceId>98 95 5 510 01</ServiceId> 
<ServiceId>98 95 5 510 02</ServiceId> 
<ServiceId>98955510 03</ServiceId> 
</ListOf Serviceld> 
< /UserParams > 
</CfCOC> 
<CfNSA> 

<Subscribed>l</Subscribed> 

<AdminStatus>l</AdminStatus> 

<UserParams> 

<Active>true</Active> 
<StartTod>00 : 00 : 00+05 : 00</StartTod> 
<StopTod>06 : 00 : 00+05 : 00</StopTod> 
<ListOf Serviceld> 

<ServiceId>98 955510 01</Serviceld> 
<ServiceId>98 955510 02 </ServiceId> 
<ServiceId>98955510 03</ServiceId> 
</ListOf Serviceld> 
< /UserParams > 
</CfNSA> 
</ListOfCallFeatures> 
</PcspService> 
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B.2 PcspEndpoint Object Example 

<?xml version="l . 0" encoding="UTF-8" ?> 

<PcspEndpoint xmlns="http : //www. cablelabs . com/Pcsp/IOl/schema" 

xmlns :pcsp="http : //www. cablelabs . com/Pcsp/IOl/schema" xmlns :xsi = "http : //www. w3 . org/2 1/XMLSchema- 

instance" > 

< ! - - 

A sample Endpoint object. 

- - > 

<EndpointId>aaln/l@mta01 . cablelabs . com</EndpointId> 

<AdminStatus>2</AdminStatus> 

< Protocol >MtaDefault< /Protocol > 

<Codec>2</Codec> 

<IPSecControl>true</IPSecControl> 
</PcspEndpoint> 



B.3 PcspMTA Object Example 



<?xml version="l . 0" encoding="UTF-8" ?> 

<PcspMta xmlns ="http : //www. cablelabs . com/Pcsp/IOl/schema" 

xmlns :pcsp="http : //www. cablelabs . com/Pcsp/IOl/schema" xmlns :xsi="http : //www.w3 . org/2 1/XMLSchema- 

instance" xsi :noNamespaceSchemaLocation="PcspI01 .xsd" > 

< ! - - 

A sample MTA object. 

- - > 

<MtaFqdn>mta01 . cablelabs . com</MtaFqdn> 

<ListenPort>242 7</ListenPort> 

<CmtsFqdn>cmta01 . cablelabs . com</CmtsFqdn> 

<Timezone>-050 0</Timezone> 

<Protocol>MCGP 1.0 NCS 1 . 0</Protocol> 

<Codec>5</Codec> 

<IPSecControl>true</IPSecControl> 
</PcspMta> 



B.4 PcspCMS Object Example 



<?xml version="l . 0" encoding="UTF-8" ?> 

<PcspCms xmlns ="http : //www. cablelabs . com/Pcsp/IOl/schema" 

xmlns :pcsp="http : //www. cablelabs . com/Pcsp/IOl/schema" xmlns :xsi = "http : //www. w3 . org/2 1/XMLSchema- 
instance" > 
< ! - - 

CMS object. 

Not much defined yet. . .just its key. 

Serves as a collection for Services and Endpoints. 
- - > 

<CmsFqdn>cma01 . cablelabs . com</CmsFqdn> 
</PcspCms> 



B.5 PcspRelation Example 



<?xml version="l . 0" encoding="UTF-8" ?> 

<PcspRelation xmlns="http : //www. cablelabs . com/Pcsp/IOl/schema" 
xmlns :xsi="http : //www.w3 . org/2 01/XMLSchema- instance" 

xsi : schemaLocation="http : //www. cablelabs . com/Pcsp/IOl/schema PcspIOl .xsd" relOp="add" > 
< ! - - 

A PcspRelation. 

This relation associates several Endpoints to the Service "9785551212". 
- - > 

<Classl>PcspService</Classl> 
<Key>978 55512 12 </Key> 
<Class2>PcspEndpoint</Class2> 
<ListOf Keys> 
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<Key>aaln/l@mta01 . cablelabs . com</Key> 
<Key>aaln/l@mta02 . cablelabs . com</Key> 
<Key>aaln/l@mta03 . cablelabs . com</Key> 
<Key>aaln/l@mta04 . cablelabs . com</Key> 
</ListOfKeys> 
</PcspRelation> 
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Annex C (informative): 
Sample Object Extension 

C.1 Extended PcspService Object Example 

The following example illustrates the extension capabilities of the PCSP schema. The example extends a PcspService 
object with a new call feature and several new elements on the main body of the object. 

<?xml version="l . 0" encoding="UTF-8" ?> 
< ! - - 

An example illustrating how to extend a Pcsp object. 

This example extends the PcspService object with additional 

fields and call features. 

See details below. 
- - > 

< PcspService xmlns="http : //www. cable labs . com/Pcsp/IOl/schema" 
xmlns :xsi="http : //www. w3 . org/2 01/XMLSchema- instance" 
xmlns :pcsp="http : //www. cablelabs . com/Pcsp/IOl/schema" > 

< ! - - 

The main body of the Service object is filled with sample data that will 
allow the object to validate. 

- - > 

<ServiceId>5551212</ServiceId> 
<AdminStatus>0</AdminStatus> 
<BillingId>5551212</BillingId> 
<ExternalId>5551212</ExternalId> 
<IsPrimary>true</IsPrimary> 
<PrimaryRing/> 
<DisplayName/> 
<DisplayNumber/> 
<Password/> 
<Announcements> 

<Language >EN< /Language > 

<Timezone>+0500</Timezone> 
< /Announc ement s > 
<InterExchange> 

<PIC>0</PIC> 

<LPIC>0</LPIC> 

<IPIC>0</IPIC> 
< / InterExchange> 
<LNP> 

< Port ingStatus>l</ Port ingStatus> 

<LNPT>true</LNPT> 
</LNP> 

< ! - - 

A Service object can be extended in two locations: 

1. The main body of the object. 

2. The call feature list. 

Here we extend the set of call features with the CfXYZ call feature. 

1. The VendorExt element requires to specify a valid namespace for the extension's schema. 
This allows 

the parsing system to locate the schema file for the extension. 

2. Any content within the VendorExt element requires to be namespace qualified, enabling 
validation against 

the extension's schema. 

- - > 
<ListOfCallFeatures> 

< Ext ens ion xmlns : ext="http : //www. cablelabs . com/SampleExtension" > 
<ext :CfXYZ> 

<ext : Subscribed>true</ext : Subscribed> 
<ext : Enabled>true</ext : Enabled> 
</ext :CfXYZ> 
</Extension> 
</ListOfCallFeatures> 

< ! - - 

Here, we extend the data content of main body of the Service object. 

- - > 
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<Extension xmlns : ext="http : / /wtni . cablelabs . com/SampleExtension" > 

<ext :A>Sample extension A</ext:A> 

<ext :B>Sample extension B</ext:B> 

<ext : C>Sample extension C</ext:C> 
</Extension> 
</PcspService> 



C.2 The Extension Schema 

<?xml version="l . 0" encoding="UTF-8" ?> 
< ! - - 

The schema for the sample PcspService extension. 

This schema defines several extensions: 

A, B, and C for the main body of the Service object. 
Call feature CfXYZ for the Service's call feature list. 
- - > 

<xs : schema targetNamespace="http : //www. cablelabs . com/SampleExtension" 

xmlns :xs="http : //www. w3 . org/2 001/XMLSchema" xmlns="http : //www. cablelabs . com/SampleExtension" 
elementFormDefault=" qualified" > 

<xs:element name="A" type="xs : string"/> 
<xs:element name="B" type="xs : string"/> 
<xs:element name="C" type="xs : string"/> 
<xs: element name= " CfXYZ " > 
<xs : complexType> 
<xs : sequence> 

<xs: element name=" Subscribed" type="xs : boolean" /> 
<xs: element name=" Enabled" type="xs : boolean" /> 
</xs : sequence> 
</xs : complexType> 
</xs : element> 
</xs : schema> 
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Annex D (normative): 

WSDL Document For PCSP Messaging 

<?xml version="l . 0" encoding="UTF-8" ?> 
< ! - - 

The IPCablecom CMS Subscriber Provisioning interface. 

Specified in Web Service Description Language 1.1. 
- - > 

<def initions name="PcspI01Service" targetName space ="http : //www. IPCablecom. com/pcsp/iOl" 
xmlns : tns="http : //www. IPCablecom. com/pcsp/iOl" xmlns : soap="http : //schemas .xmlsoap . org/wsdl/soap/" 
xmlns :xsd="http: //www.w3 . org/2 1/XMLSchema" 
xmlns : soapenc="http : //schemas .xmlsoap .org/ soap/encoding/" 
xmlns :wsdl="http : //schemas .xmlsoap .org/wsdl/" xmlns="http : //schemas .xmlsoap .org/wsdl/" > 

< ! - - 

The <types> section defines custom datatypes required by the interface. 

PCSPIOl requires two custom datatypes: 
PcspArg {and array of) 
PcspObj {and array of) . 

// PcspArg {pseudo code) 

// 

class PcspArg 

{ 

// EntityName and key of a specific object. 

// Wildcard are currently not permitted. 

// Key is ignored when entity is PcspRelation. 

// 

String entityName; 

String key; 

// Reserved for future use. Set to for now. 

// 

int flags; 

} 

// PcspObj {pseudo code) . 

// 

class PcspObj 

{ 

// EntityName and key of the specific object. 
// Key is ignored when entity is PcspRelation. 

// 

String entityName; 

String key; 

// cmdStatus : 

// PcspObj as method output/result - shall be set to one of the status codes specified 
below. 

// PcspObj as input to Put { ) - shall be set to one of the following: 

// 1, create new object 

// 2, modify existing object. 

// This field is ignored when entity is PcspRelation. 

// 

int cmdStatus ; 

// XML encoding per PCSP Data Model Schema or {null) 

// 

String xmlEncoding; 

} 

EntityNames; shall be one of the following: 

"PcspService" 

"PcspMta" 

"PcspEndpoint" 

"PcspCms" 

"PcspRelation" 

Status codes: Used for method output or contained in the cmdStatus field of a PcspObj result 
{output) . 

, Operation succeeded 
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1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 



Object not found 

Invalid Put { ) mode specified. 

Object creation failed, object already exists 

Read op failed 

Create op failed 

Modify op failed 

Delete op failed 

Internal problem. 

Server Busy 

Unsupported operation. 

Vendor extension. 



. . .extended as needed. . . 
- - > 

<types> 

< schema xmlns="http : //www. w3 . org/2 01/XMLSchema" 
targetNamespace="http : //www. IPCablecom. com/pcsp/iOl" > 
<complexType name="PcspObj " > 
<sequence> 

<element name="entityName" type=" string" /> 
<element name="key" type=" string" /> 
<element name="cmdStatus" type="int"/> 
<element name="xmlEncoding" type="string"/> 
</sequence> 
</complexType> 

<complexType name="ArrayOf PcspObj "> 
< c omp lexContent> 

<restriction base="soapenc : Array" > 

<attribute ref ="soapenc : arrayType" wsdl : arrayType="tns : PcspObj []"/> 
</restriction> 
</complexContent> 
</complexType> 

<complexType name="PcspArg" > 
<sequence> 

<element name="entityName" type="string"/> 
<element name="key" type="string"/> 
<element name=" flags" type="int"/> 
</sequence> 
</complexType> 

<complexType name="ArrayOf PcspArg" > 
<complexContent> 

< restrict ion base="soapenc : Array" > 

<attribute ref ="soapenc : arrayType" wsdl : arrayType ="tns : PcspArg [] "/> 
</restriction> 
</complexContent> 
</complexType> 
</schema> 
</types> 
< ! - - 

Message section. 

Invoking a method on the interface involves two "messages". . .an input message and an output 
message . 



"In" contains the set of input args to the method call. 

"Out" contains the return values. 
- - > 
<message name="GetOIn" > 

<part name="args" type="tns lArrayOf PcspArg"/> 
</message> 
<message name="GetOOut" > 

<part name="Result" type="tns lArrayOf PcspObj "/> 
</message> 
<message name="PutlIn" > 

<part name="objs" type="tns lArrayOf PcspObj "/> 
</message> 
<message name="PutlOut" > 

<part name="Result" type="tns lArrayOf PcspObj "/> 
</message> 
<message name="Delete2In" > 

<part name="args" type="tns lArrayOf PcspArg" /> 
</message> 
<message name="Delete20ut" > 

<part name="Result" type="tns lArrayOf PcspObj "/> 
</message> 
<message name="CmdStatus3In" > 

<part name="isCmd" type="xsd:boolean"/> 

<part name="code" type="xsd: int"/> 

<part name=" subcode" type="xsd: int"/> 
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<part name="vendorExtension" type="xsd: string"/> 
</message> 
<message name="CmdStatus30ut" > 

<part name=" Result" type="xsd: int"/> 
</message> 

< ! - - 

Port type defines the interface. 

Each "operation" is a method on the interface, with associated input and output messages 
(args and return values) . 

// The PCSP service interface {in pseudo code) . 

// 

interface IPcspIOlService 

{ 

// Get (read) one or more objects from the server. 

// EntityName of "PcspRelation' it not allowed {objects only) 

// 

PcspObj [] Get {PcspArg [] args) ; 

// Put (write) objects and relations to the server. 

// 

PcspObj [] Put {PcspObj [] objs); 

// Delete objects and relations from the server. 

// 

PcspObj [] Delete {PcspArg [] args) ; 

// Out-of-band command and status reporting. 

// 

// Predefined command codes: 

// - extension command 

// 

// Predefined status codes: 

// - extension status 

// 

int CmdStatust {boolean cmd, // true for CMC, false for STATUS. 

int code, // CMD or STATUS code {see above) . 

int subcode // Subcode. Further refines code. 

String extension) ; 

} 

- - > 

<portType name="PcspI01Service"> 

<operation name="Get" parameterOrder="args" > 

<input name="GetOIn" message="tns :GetOIn"/> 

<output name="GetOOut" message="tns :GetOOut"/> 
</operation> 
<operation name="Put" parameterOrder="obj s" > 

<input name="PutlIn" message="tns : PutlIn"/> 

<output name="PutlOut" message="tns : PutlOut"/> 
</operation> 
<operation name="Delete" parameterOrder="args" > 

<input name="Delete2In" message="tns :Delete2In"/> 

<output name="Delete20ut" message="tns :Delete20ut"/> 
</operation> 
<operation name="CmdStatus" parameterOrder="isCmd code subcode vendorExtension" > 

<input name="CmdStatus3In" message="tns : CmdStatus3In"/> 

<output name="CmdStatus30ut" message="tns : CmdStatus30ut"/> 
</operation> 
</portType> 

< ! - - 

Bind the interface {"portType") to transport specifics. 
Essentially, each method's input and output flow is bound as a 
remote procedure call using SOAP 1.1. 

- - > 

<binding name="PcspI01Service" type="tns : PcspIOlService" > 

<soap : binding style="rpc" transport ="http : //schemas .xmlsoap .org/soap/http"/> 
<operation name="Get"> 

<soap : operation soapAction="Get" style="rpc"/> 
<input name="GetOIn" > 

<soap :body use=" encoded" namespace="http : //www. IPCablecom. com/pcsp/iOl" 
encodingStyle="http : //schemas .xmlsoap .org/ soap/encoding/ "/> 
</ input > 
<output name="GetOOut" > 

<soap :body use=" encoded" namespace="http : //www. IPCablecom. com/pcsp/iOl" 
encodingStyle="http : //schemas .xmlsoap .org/ soap/ encoding/" /> 
< /output > 
</operation> 
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<operation name="Put"> 

<soap : operation soapAction="Put" style="rpc"/> 
<input name="PutlIn" > 

<soap :body use=" encoded" namespace="http : //www. IPCablecom. com/pcsp/iOl" 
encodingStyle="http : //schemas .xmlsoap . org/soap/encoding/"/> 
</ input > 
<output name="PutlOut" > 

<soap :body use=" encoded" name space ="http : //www. IPCablecom. com/pcsp/iOl" 
encodingStyle="http : //schemas .xmlsoap .org/ soap/ encoding/ "/> 
< /output > 
</operation> 
<operation name="Delete" > 

<soap : operation soapAction="Delete" style="rpc"/> 
<input name="Delete2In" > 

<soap :body use=" encoded" namespace="http : //www. IPCablecom. com/pcsp/iOl" 
encodingStyle="http : //schemas .xmlsoap .org/ soap/ encoding/ "/> 
</ input > 
<output name="Delete20ut" > 

<soap :body use="encoded" namespace="http : //www. IPCablecom. com/pcsp/iOl" 
encodings tyle="http : //schemas .xmlsoap. org/ soap/encoding/" /> 
< /output > 
</operation> 
<operation name="CmdStatus" > 

<soap : operation soapAction="CmdStatus" style="rpc"/> 
<input name="CmdStatus3In" > 

<soap :body use=" encoded" name space ="http : //www. IPCablecom. com/pcsp/iOl" 
encodingStyle="http : //schemas .xmlsoap . org/soap/encoding/"/> 
</ input > 
<output name="CmdStatus30ut" > 

<soap :body use=" encoded" namespace ="http : //www. IPCablecom. com/pcsp/iOl" 
encodingStyle="http : //schemas .xmlsoap .org/ soap/ encoding/ "/> 
< /output > 
</operation> 
</binding> 
< ! - - 

The top level definition of the PCSP 101 Service. 

Note that the <service> element does not contain an address. It is assumed that the actual 
address 

of the service will be set explicitly within the client and server. 
- - > 
<service name="PcspI01Service" > 

<documentation>IPCablecom CMS Subscriber Provisioning Service 101</documentation> 
<port name="PcspI01Service" binding="tns : PcspIOlService" > 

<soap : address location=" "/> 
</port> 
</service> 
</def initions> 
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Annex E (informative): 
Data Encoding Evaluation 

Options considered for the encoding of data objects and messaging follow. 



E.1 XML 



XML is a standard meta-language that allows organizations to design their own markup languages for document 
publishing and data exchange. Such markups are text based: designed to be obvious to both people and processes. XML 
offers: 

Open, standards based, platform independent data exchange. 

Standardized parsers for putting data into memory. 

Standardized interfaces (tree-oriented and stream-oriented) for processing the data. 

Standardized ways to display data. 

Standardized ways to query data. 

Standardized ways to link data. 

Standardized training of people in both publishing and data processing. 

The cost: somewhat larger encoding size and increased parsing overhead. 

The XML document is supervised by the XML Working Group of the World Wide Web Consortium (W3C). Special 
Interest Groups of experts from various fields contribute. It is a public standard - it is not the proprietary development of 
any company. The vLO document was accepted by the W3C as Recommendation on Feb 10, 1998 [i.6]. The document 
may be found at http://www.w3.org/TR/REC-xml . 



E.2 ASN.1/BER 



ASN.l is a text based, platform independent syntax used to represent arbitrary data structures. Is it popularly employed 
for SNMP MIB representations. The Basic Encoding Rules is a simply recursive algorithm that produces a compact 
octet encoding from an ASN. 1 description. BER encodes each item as a tag, indicating what type it is, a length 
indicating the size of the object, and a value, which contains the actual contents of the object. 

See table E.l at end of this clause. 



E.3 Proprietary ASCII 

Proprietary encodings are out of scope. 

E.4 SDP (session description protocol) 

Not flexible in term of contents. Used primarily to describe streaming media capabilities. 



ETSI 



48 



ETSI TS 1 03 1 61 -1 7 V1 .1 .1 (201 1 -04) 



E.5 RADIUS 



Radius data encoding (TLV) is too primitive and cannot enforce sequencing. RADIUS is difficult and limited to code 
structures. 



E.6 SQL 



Tied to a specific relational database implementation/schema. Some vendors may already have databases deployed with 
incompatible schema. 



E.7 Options Summary 



Table E.I : Data Encoding Options 



Option 


Pro 


Con 


XML 


Flexible, ASCII tag-based 

Provides syntax checking through use of 

schema/DTD. 

Easy to extend without effecting transport. 

Allows for vendor extensions. 

Platform-independent 

Language-independent 


Not secure, requires a secure transport layer. 
Will consume more CPU and network capacity 
than a binary encoding. Parse time, etc. 


ASN.1/BER 


Hierarchical structure for formatting of 
data. Defines a language for describing 
the data format (or "schema"). 
Data structures can be nested. 
Data is formatted in a platform 
independent way. 

Format can be extended IF the design 
includes a way of versioning the format so 
that the application knows which format it 
needs to use to parse the data content. 


ASN.1 is not easily extensible. 

Backward compatibility of format versions can 

be difficult to incorporate into the design and to 

implement. 

IVIost implementations use compiled binary 

level parsers for each schema, which means 

that defining flexible applications becomes 

quite difficult. 

Debugging applications and their 

interoperability can be difficult in that a small 

formatting error can render a data "packet" 

unparseable/unreadable. 


Proprietary ASCII 


Out of scope 


Out of scope 


SDP 

(Session Description) 




Not Flexible in term of contents. 

Used primarily to describe streaming media 

capabilities. 


RADIUS 




Radius data encoding (TLV) is too primitive. 

Cannot enforce sequencing. 

Difficult and limited to code structures. 


SQL 




Tied to relational database schema 
implementation - which some vendors may not 
use. 



E.8 Recommendation: XIVIL 



XML provides a platform-agnostic, technology-neutral form of structuring messages and packaging data. It is an 
excellent choice to send data between heterogeneous applications without each application having to know about the 
proprietary format of the other. Because XML is a structured language, it is a good fit for hierarchical types of 
messages. Data can be easily mapped to elements, so the XML document (as a tree structure) takes care of the hierarchy 
maintenance. The costs: increased wire payload sizes and increased marshalling times (parsing) for objects. 
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Annex F (informative): 
Transport Protocol Evaluation 

F.1 TFTP with IPsec 

TFTP is already in use within the IPCablecom infrastructure (DOCSIS). It is intended as a lightweight file transfer 
protocol. 

F.2 Batched RADIUS - multiple records in single request 
via event msgs 

RADIUS is an IETF standard created primarily to handle Internet dial-up authentication, authorization, and accounting. 
RADIUS is currently the de facto standard used by most router manufacturers for such activities. Several vendors of IP 
telephony gateway equipment are already utilizing RADIUS' support for vendor extensions to deliver the information 
needed for billing. 

RADIUS defines both a transport protocol and a document for message formats. As a transport protocol, RADIUS 
relies on user datagram protocol (UDP) for message broadcast and is port -based. 

As a message format, the data is formatted based on tag-length-value (also called attribute-length- value). Standard 
authentication, authorization, and accounting tags are pre-defmed and are minimally required. However, new attributes 
can be added without disturbing existing implementations of the protocol. RADIUS has a minimum total message 
length of 20 characters and a maximum length of 4 096 characters. Individual data fields support 247 bytes of data, for 
example, a 247 character URL or filename. 

RADIUS has very poor reliability characteristics and essentially non-existent error recovery, and is very limited in new 
tags (can only define a total of 255) (compare that to 600 existing features in some PSTN class 5 switches). 



F.3 Diameter 

Diameter represents an activity in the working group of the IETF that is designed to be backward compatible to 
RADIUS. It is much more extensible, has increased security benefits, and is designed to minimize configuration. In 
addition, it supports cross-domain AAA very well by supporting a variety of security schemes such as public key, etc. 
Diameter supports fail-over to a backup server (it is designed for environments that have low failure requirements 
(99.99H-)). 

RADIUS/DIAMETER does not provide two-way communication (only acknowledgments); therefore, it does not fulfil 
the requirements. 



F.4 Distributed Object Systems 
F.4.1 CORBA/IIOP 

The distributed object technology championed by the Object Management Group. There are upwards of 800 OMG 
members behind this technology. 
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The Common Object Request Broker Architecture (CORBA) allows applications to communicate with one another by 
using an Object Request Broker (ORB). The ORB is middleware that establishes the client-server relationships between 
objects. The ORB registers clients and manages rights such as publish, subscribe and listener. Using an ORB, a client 
can transparently invoke a method on a server object, which can be on the same machine or across a network. The ORB 
intercepts the local call and is responsible for finding an object that can implement the request, pass it the parameters, 
invoke its method, and return the results. 

The Interface Definition Language (IDL) is used to establish the ORB protocol contract between client and server 
objects. The ORB essentially hides the transportation details from the programmer. The IDL is complied into C++, 
Java, etc. implementations of client and server stubs, handling all data encoding/decoding chores required by the HOP 
transport protocol used between clients and servers. 

CORBA will handle the details of finding the server for a method call, transporting arguments from the client machine 
to the server machine, and transporting any return code back to the client machine. 

ORBs are currently available from many vendors for more than three dozen hardware platforms and operating systems. 
CORBA is particularly popular on *nix platforms. However, in practice, ORB vendors compete on features. Persistent 
interoperability problems exist when one gets past the basics (security, etc.). The likelihood of two randomly selected 
ORBs being able to successfully communicate is low. From a development standpoint, CORBA tends to be very 
complex. Additionally, CORBA is a relatively expensive option (runtime and development licenses). 



F.5 DCOM 



Microsoft's Distributed Component Object Model. Shares the following characteristics with CORBA: 

• Separates object interface from implementation. This is accomplished using MIDL (Microsoft's IDL variant). 

• Allows transparency of location. Clients invoke methods on remote objects without knowing which machine 
the remote object runs upon. 

• Uniform exception handling scheme (DCOM method calls return a flat HRESULT return status). 
However: 



• 



DCOM is based on DCE ORPC transport protocol, which in incompatible with HOP transport used by 
CORBA. 

DCOM is basically a Microsoft only technology. It is standard on Win95, Win98 and NT platforms. 



F.6 HTTP 

Hypertext Transfer Protocol (HTTP) is the primary protocol for the World Wide Web. HTTP was designed to connect 
heterogeneous data sources together to create a distributed information system. It was also designed with extensibility in 
mind. A typical HTTP transaction: 

1) client established connection to the server; 

2) client issues a request to the server (with URL parameters); 

3) server sends response containing status and requested URL; 

4) either side can disconnect. 

HTTP provides transaction headers for both client requests and server responses. The client transaction header can 
include parameters used to assist delivery of the desired information to the client (e.g. type of data format, language 
etc). The server transaction header can include parameters indicating information about the response (e.g. the status of 
the request (return code), the length of the data being sent, the content type, the language of the content, etc.). 

Given the current state of the Web, HTTP is ubiquitous. It is also firewall friendly. 
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F.7 Options Summary 



See table F. 1 for transport options. 



Table F.I : Transport Options 



Option 


Pro 


Con 


TFTP with IPSEC 


Lightweight 

Already implemented for DOCSIS 


Does not provide two way communication 


RADIUS 


Flexible - includes vendor-specific and 
customer-specific fields. IPCablecom may be 
able to define fields in this space. 
Used by many IP telephony accounting systems 
Already widely deployed on IP components such 
as routers. 


Not all RADIUS products support AAA 

Application layer needs to handle reliability 

issues 

Inadequate built-in security, need an 

independent trust protocol or shared secret keys 

with edge routers 


Socket based 
proprietary 
protocol with SSL 




Proprietary. If pursued, we will probably end up 
writing most of what is currently available in 
SOAP or XMLP. 


CORBA/IIOP 


Easy to implement, details of name resolution, 
packaging parameters into messages and 
transport are all managed by the CORBA 
infrastructure 


Tends to be a more expensive solution. The 
CORBA infrastructure requires to either be 
developed or purchased, and in either case it 
requires to be deployed with the application. 
There may still remain issues re: interoperability 
or various CORBA/ORB products. 


DCOM 


DCOIVI and CORBA/IIOP are similar 
technologies. 


Basically a IVIicrosoft Windows only option. 
Will not inter-operate with CORBA-IIOP. 


HTTP 


HTTP already widely deployed as an underlying 
transport protocol for exchange between data 
sources (web servers) and data consumers 
(client browsers). 

Data transmission based on simple transactions. 
Simple, stateless, ASCII text based protocol. 
Allows for easy data exchange through most 
currently deployed network infrastructure 
(firewalls, etc.). 

Client can use simple method calls when 
making requests as - GET, POST, HEAD, PUT, 
DELETE, LINK, and UNLINK. 


Being Stateless, the protocol has no memory of 

the transaction once it finishes. 

Can it keep up with required CIVIS transaction 

rate? 

Relatively expensive in terms of bandwidth and 

processing requirements. 



F.8 Recommendation: HTTP 1.1 

Based on the analysis above, it is recommended that HTTP 1.1 be the transport protocol used. 
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